Traffic flowing from an application running on one computer to an application running on another computer might pass through several network elements such as operating system queues, network adapter cards, LANs, routers, and the like. Each element transmits data at a finite rate so each element has the potential to slow the passage of the traffic. Congestion occurs whenever the rate at which data are sent to a network element exceeds the rate at which the network element transmits the data. Network elements may cope with congestion by queuing data until the congestion subsides or by discarding data to alleviate the congestion.
As a result of the methods of handling congestion, applications face variations in the time needed to transport data (network latency) and in the amount of data lost in transmission. Applications differ from one another in how tolerant they are of these variations. Real-time video and audio applications, for example, cannot tolerate large variations in either latency or in data loss.
Some networks issue Quality of Service (QoS) guarantees concerning their ability to support the specific traffic requirements of applications. QoS guarantees are implemented in a network by allocating scarce resources to application traffic flows in a manner that meets the applications' traffic requirements. For example, a congested network element might queue the traffic of applications that are tolerant of latency while transmitting latency-sensitive traffic without delay. When the congestion clears, the queued traffic may be sent.
While the benefits of QoS guarantees are generally acknowledged, those benefits are difficult to measure accurately. For example, some existing tools attempt to measure latency by transmitting a large amount of data and then determining how much time passes until the data are received. This technique gives, at best, a very coarse measurement of latency, averaged over the entire period of transmission. Measurement techniques such as “pinging” the receiver are more accurate, but merely provide average, round-trip latency information. In reality, the latency may be substantially different in the two directions, and that difference may be significant to an application that streams video or audio.
Another problem with measuring latency stems from differences in the clocks on the sending and receiving computers. Measurements based on the difference between the time of transmission as measured on the sending computer and the time of reception as measured on the receiving computer depend upon a careful synchronization of the two clocks. Complex latency measurement tools exist, often relying on radios, satellite receivers, or modems to synchronize the clocks of the sender and receiver, but these tools are often expensive and serve only to bound the problem, not to eliminate it.
The invention described in U.S. patent application Ser. No. 09/537,995, “Method and System for Accurately Calculating Latency Variation on an End-to-End Path in a Network,” filed on Mar. 29, 2000, advances the art of QoS measurement by focusing on variations in latency (jitter) rather than on latency itself. The invention generates a predetermined number of packets on a sending computer. The packets are timestamped with the sender's local time and then sent over the network to a receiver. When a packet arrives at the receiver, it is similarly timestamped with the receiver's local time. The difference in the timestamps for each packet is recorded. These records provide only a rough measurement of latency because the clocks are not synchronized, but the variation among the records is an accurate measurement of network jitter. Measurements can be run with and without QoS mechanisms in place to see how well those mechanisms even out transport variations.
For some applications, however, the invention described in Ser. No. 09/537,995 is not adequate because it relies on a traffic flow generated by the measurement tool itself. Introducing that traffic flow into the network may distort the characteristics of network traffic so much that the resulting jitter measurements do not accurately indicate the conditions faced by an application. Also, the patterns of traffic generated by certain applications may be very complex and may not be well modeled by a tool that sends fixed-size packets at a fixed rate. What is desired is a tool that measures network jitter using packets generated by an application rather than packets generated by the tool itself.